home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Jan 90 / MacApp.Tech$ 1⁄12⁄90 / 0390-Re Instantiation “by-Jan90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.1 KB  |  54 lines  |  [TEXT/GEOL]
  1. Item    4161816                         11-Jan-90        09:52
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     FALK2                           Austria - Alexander Falk
  6.         MACAPP.TECH$                    MacApp Technical
  7.  
  8. Sub:    RE>Instantiation “by clas
  9.  
  10. Attn: Austria - Alexander Falk
  11. Attn: MacApp Tech
  12. SentBy: Larry Rosenstein
  13. Date   1/11/90
  14. Subject    RE>Instantiation “by classn
  15. From   Larry Rosenstein
  16. To Austria - Alexander Falk
  17.    MacApp Tech
  18.  
  19.          Reply to:   RE>Instantiation “by classname
  20. In MacApp 2.0b9, there's a way to instantiate any object given its class name.
  21.  This is using the function NewObjectByClassName.
  22.  
  23. The RegisterStdType procedure is used to give a type name a 4-character alias.
  24.  You can then instantiate an object given its alias (or signature) with a call
  25. to NewStdObject.
  26.  
  27. There are 2 reasons for doing this.  One is that it saves space in the view
  28. resource.  Instead of using the full class name, you can use just the
  29. 4-character signature.
  30.  
  31. Second, it adds another level of indirection in view creation.  If all
  32. instances of TWindow (for example) are created by based on its 4-character
  33. signature ('wind') then one can easily substitute a different window class by
  34. registering a different type with the same signature.
  35.  
  36. This provides a limited way to customize MacApp without changing its source
  37. code.  Suppose you modified TTEView to have a new capability.  You can then
  38. register your subclass with the same signature as TTEView, then any view
  39. resource that refers to TTEView by signature will get your modified class
  40. instead.
  41.  
  42. The part about inhibiting dead code stripping is a kludge, and one usually
  43. gets bitten by it the first time you instantiate a custom class by name (after
  44. the linker has stripped the class).  It is desirable for the linker to strip
  45. classes that aren't created.  It is impossible (in general) for the linker to
  46. know if a class is instantiated by name.  Therefore, you have to explicitly
  47. tell it.  A better solution, however, you be a linker option that listed the
  48. class names used in the program.
  49.  
  50. Larry Rosenstein
  51.  
  52.  
  53.  
  54.